home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / FREENET / BRODIE / FREESMTP / ReadMeNOW!
Text File  |  1997-08-25  |  37KB  |  992 lines
  1. !FreeSMTP 1.23
  2. ==============
  3.  
  4. Contents:
  5.     Copyright & Disclaimer
  6.     Important Changes in this Version
  7.     Installation Instructions
  8.     Upgrading from Earlier versions
  9.     Configuration Instructions
  10.         Why does all email get sent to "localhost"
  11.     Operating Advice
  12.         for people with permanent links
  13.         for people with transient dialup links
  14.     Running & Stopping !FreeSMTP
  15.     What to do if you get the error message:
  16.         Loopback interface is not configured/up
  17.         Loopback interface is configured - but not up
  18.     Kicking the sender
  19.     Activity log
  20.     References
  21.     Bug Reporting
  22.     Technical Details
  23.         MX records explained
  24.         Security Considerations
  25.         Ident
  26.     ChangeLog
  27.  
  28.  
  29. **** WARNING: Incorrect configuration can cause you to be in breach
  30. **** of your provider's terms & conditions.  Full details under the
  31. **** configuration section below, in the subsection "forwarder"
  32.  
  33.  
  34.  
  35.  
  36. Copyright & Disclaimer
  37. ----------------------
  38.  
  39. This program is copyright (C) Stewart Brodie, 1996, 1997
  40.  
  41. The author accepts no liability for any damage or loss of any kind incurred,
  42. or allegedly incurred, by the use, or misuse, of this software.  The program
  43. may do its absolute best to ensure that incoming mail is either stored
  44. successfully in the incoming (or outgoing) mail spool appropriately, or that
  45. the sender is informed that the delivery attempt was unsuccessful and should
  46. be retried (or not as appropriate).
  47.  
  48. Having said all that, I do want people to use it and find any problems.  I'm
  49. afraid that some people's attitude make all those disclaimers necessary.  For
  50. normal usage, there shouldn't be any problem, and the programs try very hard
  51. indeed to prevent any loss occurring (eg. by not acknowledging successful
  52. reception of an e-mail until it has been successfully stored in the spool
  53. directory completely).  If the program fails, then in the vast majority of
  54. cases the upstream SMTP will have received a rejection from this program
  55. (unrequested connection termination counts as a rejection unless the 250
  56. response to the final '.' of a DATA body is received at the sender).  If the
  57. sender half of this software fails, then it it will construct a failure
  58. message and return that directly to the message originator.
  59.  
  60.  
  61.  
  62. Important Changes in this Version
  63. ---------------------------------
  64.  
  65. This version uses *SMTPServerTaskWindow to start up the server and client
  66. tasks.  This must be set correctly for FreeSMTP to function.
  67.  
  68.  
  69. Installation Instructions
  70. -------------------------
  71.  
  72. Installation should be fairly simple and trouble free provided these
  73. instructions are followed carefully.  You will NEED Newsbase 0.55 or later
  74. in order for this to work properly - it will not like 0.54.  I have tried
  75. to include as much details as possible, so don't worry about the apparent
  76. length of it.
  77.  
  78. * Copy the Transports directory into the !Newsbase directory to install the
  79. interface programs in Newsbase. (You may find that you have to restart
  80. Newsbase now to get it to recognise the newly present transport).
  81.  
  82. * Copy the !FreeSMTP directory into a directory containing your other
  83. Internet applications, and run it in its new home (it will fail to start
  84. because there is no configuration file, but this step is necessary in
  85. order to reset the system variables to point to the correct directory)
  86.  
  87. * Open the Newsbase Transport Control window, and in the middle portion
  88. of this window, choose "in_smtpd" off the Transport menu.  You should now see
  89. the description "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)" or similar.  If
  90. you fail to get this far, then you may have forgotten to restart Newsbase or
  91. to rerun !FreeSMTP.
  92.  
  93. * Switch on the Check arrivals new mail option.
  94.  
  95. * Follows the instructions in the Configuration Instructions below
  96.  
  97. * Ensure you have a DNS resolver configuration file.  If you do not have a
  98. DNS resolver installed on your system, then you will need to get one.  You
  99. can find this out by looking for a file in !Internet.Files (or
  100. !FreeUser.Files or !InetSuite.Internet.Files) called "resconf".  If this is
  101. present, then you have already got the necessary file installed.  The
  102. resolver module is NOT used, but the configuration file it uses IS used by
  103. these programs (FreeNet (by Tom Hughes) comes with InetDB and its
  104. installation instructions; ArcWeb (my program) comes with just the
  105. installation instructions necessary)
  106.  
  107.  
  108. Upgrading from Earlier versions
  109. -------------------------------
  110.  
  111. Reinstall the Transports into !Newsbase.  If you changed the log file
  112. locations in !Run, re-edit the *new* !Run since this contains new
  113. system variables that are required.
  114.  
  115. Your mail is received into a different directory than before version 1.14.
  116. This makes it compatible with the KA9Q directory structure.
  117.  
  118. You should read the section on 'noiconbar' in the configuration section as
  119. this is a new command.
  120.  
  121.  
  122. Configuration Instructions
  123. --------------------------
  124.  
  125. There is a single configuration file for !FreeSMTP which is stored
  126. inside the !FreeSMTP directory.  This is deliberately entirely made
  127. up of comments so that the programs will refuse to load before you
  128. have edited the configuration.  You should find that you can skim
  129. through this section, modifying the file as you go.
  130.  
  131. (If !FreeSMTP.smtp-conf does not exist, then either copy it from defaultcnf
  132. in the same directory, or click on Setup in the Newsbase Transport Control
  133. window which will do this for you)
  134.  
  135. The configuration file is a sequence of directives which tell the
  136. software what your machine's real name is, what e-mail domains it
  137. hosts, and which domains it relays mail for (if any).  I have tried
  138. to provide as much flexibility as possible whilst keeping it as
  139. simple as possible for the vast majority of cases (take a look at an
  140. /etc/sendmail.cf file on a UNIX system to see how hairy it can become :-)
  141.  
  142. To edit the configuration file, choose the "in_smptd" transport in the
  143. Newsbase "Transport Control" window.  You should then see the description
  144. message "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)".  To set up the Newsbase
  145. bit, ensure that "Check arrivals: new mail" is set; Route outgoing mail is
  146. set, and a smarthost is placed in the gateway box for mail(**).  Also set
  147. in_smtpd as the Def mail route.  Then, you should click on the Setup button
  148. which will open the configuration file in your text editor ready for you
  149. to set your own site details.
  150.  
  151. (**) If you set the gateway to be your own machine, then you MUST have
  152.      an appropriate forwarder line as described below.  The line you
  153.      will need will be "forwarder * provider's-smarthost".
  154.  
  155. Provided you have set up the forwarder lines, you can tell any software
  156. you have to send outgoing mail to 'localhost'.  This will result in it
  157. being sent to the server which will then route it using the rules in
  158. smtp-conf without consulting Newsbase.
  159.  
  160. There are brief comments in the configuration file to remind you what each
  161. section is for, but these are elaborated here.  The order of the sections is
  162. not important, although the order of declarations of the same type IS
  163. important (see below for reasons) For each section I have given the syntax,
  164. an example for a Demon DialUp user with a nodename of 'customer',
  165. (applicable to other static IP single host systems too), an example for a
  166. host on a network handling mail for that network, and my own setup.
  167.  
  168.  
  169. hostname
  170. ========
  171.  
  172. Syntax:   hostname <Fully Qualified Domain Name (FQDN)>
  173. Demon DU: hostname customer.demon.co.uk
  174. Network:  hostname mail.an.org.uk
  175. My Setup: hostname delenn.ecs.soton.ac.uk
  176.  
  177. This gives the *full* hostname(s) of the machine running this software.
  178. Hosts may have more than one name in some circumstances, and this is
  179. allowed by having multiple hostname lines, although the *first* line
  180. found in the file is the one used to identify the server to remote
  181. hosts when it needs to (eg. when greeting SMTP clients)
  182.  
  183. localdomain
  184. ===========
  185.  
  186. Syntax:   localdomain <Fully Qualified Mail Domain> [<alias name>]
  187. Demon DU: localdomain customer.demon.co.uk
  188. Network:  localdomain an.org.uk
  189. My Setup: localdomain delenn.ecs.soton.ac.uk soton
  190.  
  191. [and in My Setup, <SMTPServer$Aliases>.soton contains the line:
  192. S.N.Brodie snb94r
  193. ]
  194.  
  195. This gives the local *mail* domain(s) handled by the software.  These
  196. mail domains are the things you see after the @ in mail addresses.
  197. When mail arrives, the destination is checked to see if there is any
  198. @ character in it.  If there is NOT, then the value of the *first*
  199. localdomain directive is assumed.  (This is so that the alias and user
  200. list functions can determine which set of aliases to apply)
  201.  
  202. Next, the bit after the @ is compared against each localdomain directive in
  203. turn.  If it matches any one of them, then the domain part is dropped. Next,
  204. if an alias name was specified for that localdomain, then the bit before the
  205. @ is looked up in <SMTPServer$Aliases>.aliasname to see if was a mail alias,
  206. and if so, the mail address is rewritten to match the definition of the
  207. alias.  The format of that file is described below.  You MUST be careful with
  208. that file.
  209.  
  210. Otherwise, the bit before the @ is assumed to be a mailbox in the local
  211. Newsbase. (If no domains match, then it is checked against the forwarders
  212. below).
  213.  
  214. If you wish to have an mailbox name that contains characters illegal in RISC
  215. OS filenames, then you can create an alias to convert it to something else,
  216. like I do in my alias file as shown above.
  217.  
  218. For single dialup hosts, there is likely to be a single setting which
  219. will happen to co-incide with the hostname.  For hosts serving entire
  220. domains, this is less likely. (Note that in My Setup, I accept mail for
  221. an unofficial mail domain - you won't find an MX record in the DNS for
  222. the delenn.ecs.soton.ac.uk mail domain)
  223.  
  224.  
  225. alias file format
  226. =-=-=-=-=-=-=-=-=
  227.  
  228. The format of the file is that the alias appears first on the line, and
  229. the real addresses are specified after it separated by whitespace.  If
  230. you need to use more than one line, then these continuation lines MUST
  231. start with whitespace (otherwise they are considered to be other aliases)
  232.  
  233. Although this might seem like a good way to set up a mailing list, this
  234. is NOT the case, since the original sender will be in the FROM envelope,
  235. so any forwarding errors will go to there and not to some mailing list
  236. software.
  237.  
  238. The purpose of the alias file is for *simple* rewriting and occasional
  239. duplication if you need it.  If you want to run a mailing list, then
  240. use something like !MailList.
  241.  
  242. So in My Setup mentioned above shows that any mail incoming addressed
  243. to S.N.Brodie@delenn.ecs.soton.ac.uk will be sent to snb94r.  This is
  244. useful because you can specify names which might not be acceptable as
  245. usernames to Newsbase.
  246.  
  247.  
  248.  
  249. forwarder
  250. =========
  251.  
  252. Syntax:   forwarder <"*" | F.Q. Mail Domain> <"MX" | smarthost-FQDN>
  253. Demon DU: forwarder * post.demon.co.uk
  254. Network:  forwarder * MX
  255.           forwarder * mail.smarthost.provider.org
  256. My Setup: forwarder ecs.soton.ac.uk MX
  257.           forwarder * dsse.ecs.soton.ac.uk
  258.  
  259.  
  260. This gives mail domains which are to be responded to by the software, but
  261. which are not local to this machine (ie. they need to forwarded on somewhere
  262. else, cf. localdomain).  For the vast majority of people, you will want one
  263. forwarder line (see WARNING below - having such lines may in fact
  264. contravene your provider's terms & conditions of service unless you have
  265. specifically purchased the right to forward mail).
  266.  
  267. The major purpose of the non-* entries here is when you are running FreeSMTP
  268. on the mail gateway for a domain (ie. the MX record for a domain gives
  269. the machine running FreeSMTP as one of the mail exchangers).
  270.  
  271. If there are no forwarder lines, then any mail not destined for local
  272. delivery (ie. it matched one of the localdomain lines) will be rejected when
  273. it is offered by another host (*).
  274.  
  275. If there are forwarder lines, then they are matched in order.  If the first
  276. parameter is "*", then this matches, otherwise the string has to match the
  277. bit after the @ in the destination of an incoming mail exactly.  The second
  278. parameter describes how this forwarding is to be achieved and is either the
  279. string "MX" or the FQDN of a smarthost which will do the job for you.
  280.  
  281. There are two ways of forwarding the mail - MX records, and smarthosts. Using
  282. MX records involves looking up the name of the machines which handle mail for
  283. a given mail domain (see description later in this document) and then sending
  284. the mail directly to one of those machines.  The alternative is to use a
  285. 'smarthost' (such as post.demon.co.uk) which will perform that function on
  286. your behalf (ie. it acts as an intermediate relay for you). The advantage of
  287. using MX records, is that it bypasses your provider's smarthost (less hops to
  288. the destination) and can tolerate the smarthost being down.  When MX lookups
  289. return multiple records, they are tried in turn according to the priorities
  290. specified by the DNS server. [This does seem to work, as I found out when
  291. Demon's punts weren't accepting mail and when the connection attempt to them
  292. timed out, it sent it to relay-1 instead :-) ]
  293.  
  294. (*) 'another host' could actually be your own machine.  For example, I
  295. have ArcWeb's Email configuration set up with a smarthost mail gateway
  296. of "localhost".  This means that ArcWeb will send mail by talking to the
  297. SMTP server process running on my own machine.  Thus, having no forwarder
  298. lines in my configuration would mean that I couldn't send mail that way
  299. and would have to configure a remote smarthost in ArcWeb instead.
  300.  
  301.  
  302. forwarder strategy
  303. -=-=-=-=-=-=-=-=-=
  304.  
  305. The forwarder directives which specify MX records are to be used are
  306. overridden in some circumstances, primarily for performance reasons.
  307.  
  308. If the mail has only a single recipient (or multiple recipients with the same
  309. domain) and forwarder says to use MX records, and those MX records exist,
  310. then this will happen.
  311.  
  312. If the mail has multiple recipients, then any MX directive is overridden and
  313. a smarthost is used instead *if one is defined* (because otherwise the
  314. message would have to be sent separately to each recipient).  [A future
  315. enhancement will be to still use MX records if all the destinations share a
  316. common mail exchanger]
  317.  
  318.  
  319. WARNING: Incorrect configuration of forwarder records could cause you
  320.          to be in breach of the terms & conditions of your account.
  321.          Unless you are authorised to forward mail to hosts other than
  322.          those at your provider's end of your connection, you should
  323.          only have one forwarder line:
  324.          
  325.         forwarder * post.demon.co.uk
  326.     
  327.          (where you have substituted your provider's smarthost for
  328.          post.demon.co.uk if you aren't with Demon Internet)
  329.          
  330.          The author accepts no responsibility or liability for any
  331.          such breaches of terms & conditions, nor for consequences
  332.          arising from action taken by providers against any user of
  333.          this software for such breaches even if the author has been
  334.          advised of the possibility of such breaches.
  335.  
  336.  
  337. acceptfrom
  338. ==========
  339.  
  340. Syntax:   acceptfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
  341. Demon DU: (no acceptfrom lines)
  342. Network:  (no acceptfrom lines)
  343. My Setup: (no acceptfrom lines)
  344.  
  345. ** WARNING: If you use hostnames with this command, then these must be
  346. **          resolvable when the program starts, otherwise the directive
  347. **          will be ignored.
  348.  
  349. This is used to selectively choose which remote hosts you are willing to
  350. accept mail from.  If a host other than one listed attempts to deliver
  351. mail to your machine, then it will be told that it does not have permission
  352. to deliver mail to your machine.  If there are no acceptfrom lines (as in
  353. My Setup) then any host may connect.
  354.  
  355. When specifying an IP address, you may specify the number of significant bits
  356. to be matched (as described in the rejectfrom section below)
  357.  
  358. All addresses that pass the acceptfrom directives (including the case
  359. where there are NO acceptfrom directives) are then validated against
  360. the rejectfrom directives described in the next section.
  361.  
  362. IMPORTANT:  If you have any of these fields, then you MUST include
  363. all the machine's own IP addresses and you MUST include localhost (ie.
  364. 127.0.0.1), since the outgoing sender may use these addresses when
  365. constructing error notifications and performing mail rewriting.
  366.  
  367. There is little real reason to use this facility unless you are worried
  368. about faked e-mail being sent via your site (and even then, the message
  369. is tagged with the Received line containing the IP address of the sender,
  370. allowing you to trace the source)
  371.  
  372. See also: rejectfrom, killfile
  373.  
  374. rejectfrom
  375. ==========
  376.  
  377. Syntax:   rejectfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
  378. Demon DU: rejectfrom 198.81.0.0/16
  379.           rejectfrom 152.163.172.0/24
  380. Network:  rejectfrom relay.deliverer.hackers.org
  381. My Setup: (no rejectfrom lines)
  382.  
  383. ** WARNING: If you use hostnames with this command, then these must be
  384. **          resolvable when the program starts, otherwise the directive
  385. **          will be ignored.
  386.  
  387. This is used to selectively choose which remote hosts you are NOT willing to
  388. accept mail from.  If a host covered by one of these directives, then it will
  389. be told that it does not have permission to deliver mail to your machine.  If
  390. there are no rejectfrom lines (as in My Setup) then any host may connect
  391. (subject to the acceptfrom conditions).  The Demon DU example describes that
  392. mail from 198.81.xxx.xxx and from 152.163.172.xxx will be rejected (these
  393. are the AOL mail exchangers :-)  I am not suggesting that you do this - just
  394. using it as an example of use.
  395.  
  396. IMPORTANT: You should not reject any of your machine's own IP addresses
  397. (including 127.0.0.1 (localhost)).  See also: acceptfrom, killfile
  398.  
  399. There is very little real reason to use this facility unless you have
  400. some hacker trying to send you mail, in which case you can block their
  401. IP address using this facility.
  402.  
  403.  
  404. killfile
  405. ========
  406.  
  407. Syntax:   killfile <Fully Qualified Kill File path name>
  408. Demon DU: killfile smtpserver:killfile
  409. Network:  killfile smtpserver:killfile
  410. My Setup: killfile smtpserver:killfile
  411.  
  412. This is used to kill incoming mail based on the *sender* specified
  413. in the SMTP envelope (ie. the MAIL FROM).  The file named in the
  414. directive is consulted when a new transaction is started and if
  415. the sender matches any entry, the mail is rejected.
  416.  
  417. The kill file format itself is one (wildcardable) address per line.
  418. If the kill file does not exist, nothing is killed.
  419.  
  420.  
  421. noexpand
  422. ========
  423.  
  424. Syntax:   noexpand
  425. Demon DU:
  426. Network:  noexpand
  427. My Setup:
  428.  
  429. This directive is optional and takes no parameters.  If it is present,
  430. then clients attempting an EXPN on an alias will receive a message
  431. indicating that EXPN has been explicitly disabled by the administrator.
  432.  
  433. If you don't understand the above paragraph, then you don't need this.
  434.  
  435. Normally, you'd only use this to stop people looking up the members of
  436. a mailing list of something like that.  The vast majority of people
  437. do not want this.
  438.  
  439.  
  440. noident
  441. =======
  442.  
  443. Syntax:   noident
  444. Demon DU:
  445. Network:  noident
  446. My Setup:
  447.  
  448. This directive is optional and takes no parameters.  If it is present,
  449. then the server will not attempt an ident request to the client making
  450. the connection.  See "Remote User Authentication" section below for
  451. more details of ident.
  452.  
  453. If you don't understand the above paragraph, then you don't need this.
  454.  
  455. You would only ever disable this feature for efficiency reasons.
  456.  
  457. noiconbar
  458. =========
  459.  
  460. Syntax:   noiconbar
  461. Demon DU: noiconbar
  462. Network:
  463. My Setup:
  464.  
  465. This directive is optional and takes no parameters.  If it is present,
  466. then no icon bar icon will be installed.
  467.  
  468. You would only ever disable this feature to avoid filling your iconbar.
  469. If you have this directive, the only way to stop FreeSMTP is to double-
  470. click on FreeSMTP again.
  471.  
  472.  
  473. maxhops
  474. =======
  475.  
  476. Syntax:   maxhops <maximum hop count>
  477. Demon DU:
  478. Network:
  479. My Setup:
  480.  
  481. This directive is optional and defaults to "maxhops 30".  The numeric
  482. parameter describes the maximum number of servers through which the mail is
  483. allowed to be passed before being returned to the sender as undeliverable. 
  484. Usually, mail will take at most half a dozen hops to get to the recipient. 
  485. If it is up to something more like 30 (the default here), then it is likely
  486. that a mail loop has developed (a set of servers (mis)configured to route
  487. mail for the destination domain to each other, which will just keep
  488. forwarding it back and forth forever and ever).  Once maxhops is exceeded,
  489. this server will not forward it any more, but will construct a delivery
  490. failure message and bounce it back to the sender.
  491.  
  492. Almost certainly, you do not want to override the default.
  493.  
  494.  
  495. maxsessions
  496. ===========
  497.  
  498. Syntax:   maxsessions <+ve integer>
  499. Demon DU: maxsessions 4
  500. Network:  maxsessions 4
  501. My Setup: maxsessions 4
  502.  
  503. This specifies the maximum number of sessions that may be in progress at
  504. any one time.  This is limited by the capability of the C library (and if
  505. you specify a number too large, it will be reduced to the maximum that can
  506. be supported - 4 with the current SharedCLibrary.
  507.  
  508. It is important to have this set to 4 for Demon customers, since Demon
  509. have multiple mail machines which may attempt delivery concurrently.
  510.  
  511.  
  512. Why does all email get sent to "localhost"
  513. ------------------------------------------
  514.  
  515. All e-mail sent by your machine will be sent initially to the server on your
  516. machine.  (tech: the GATE command in the work file will always be set up
  517. to be "GATE VIA:localhost").  This is deliberate, because all the mail
  518. routeing cleverness is stored in the *server* at the moment.  That software
  519. can then make the final destination decision and requeue it for sending out.
  520.  
  521. This will cause an extra Received header to be placed in the outgoing mail,
  522. and will also ensure that missing headers are inserted before the mail
  523. leaves your machine too.  
  524.  
  525. This is not a really peculiar thing to do.  Most UNIX machines I have used
  526. have done this.  It is done to simplify the coding of the mail senders and
  527. to centralise the decision making process and forwarding rule processing
  528. into a single place so that policy changes can be implemented in one go.
  529.  
  530.  
  531. Operating Advice
  532. ----------------
  533.  
  534. for people with permanent connections
  535. =====================================
  536.  
  537. Run it all the time - that's what I do.
  538.  
  539.  
  540. for people with transient dialup links
  541. ======================================
  542.  
  543. You really do want to start the TCP/IP stack and !FreeSMTP *before*
  544. connecting to the net.  This is particularly important for Demon users, since
  545. the SMTP server takes around 1 second to start up and read its configurations
  546. files and may not manage to start listening for the incoming connections
  547. before the punts attempt to deliver mail (they fail to do so, and hold on to
  548. it for a while before trying again a bit later).  This causes a slight
  549. problem with dialup lines though unless you are careful.  You *must* start
  550. the TCP/IP stack, but you do NOT need to start up the SLIP/PPP interface (if
  551. you do, your dialler won't be able to access the comms port!).  The relevant
  552. bits that must be deferred until after dialling is complete are the slattach
  553. & ifconfig commands 
  554.  
  555.  
  556. Running & Stopping !FreeSMTP
  557. ----------------------------
  558.  
  559. Run !FreeSMTP by double-clicking on the icon in the directory viewer.
  560. To stop, it double-click on the icon again (or kill SMTP Monitor in
  561. the Task display window) or choose Quit from the icon bar menu if you
  562. haven't disabled the Wimp interface (see "noiconbar" directive above)
  563.  
  564.  
  565. What to do if you get the error message:
  566.     Loopback interface is not configured/up
  567.     Loopback interface is configured - but not up
  568. -----------------------------------------------------
  569.  
  570. These two messages are new in version 1.17.  If you get them, then you
  571. will find that the program will not have started.  FreeSMTP needs the
  572. loopback interface configured.  This should have been done during your
  573. boot sequence, or whenever the TCP/IP networking software was loaded.
  574.  
  575. If you get the latter of the messages (which would be unusual unless
  576. you were fiddling around), then you need to issue the command:
  577. "*ifconfig lo0 up" at the command line or insert this in the networking
  578. startup files.
  579.  
  580. If you get the former, then you need to insert the slightly longer:
  581. "*ifconfig lo0 inet 127.0.0.1 up".
  582.  
  583. Once these commands have been executed, FreeSMTP should load.   If it
  584. still doesn't, then the chances are you that are using an old version of
  585. FreeNet.  Edit !FreeSMTP.!Run and insert the following line:
  586.  
  587. Set SMTPServer$NoSearch 1
  588.  
  589.  
  590. (See also: Why does all email get sent to "localhost")
  591.  
  592.  
  593.  
  594. Kicking the sender
  595. ------------------
  596.  
  597. The sender program (out_smtpd) is automatically launched (by SMTP Monitor)
  598. after in_smtpd has queued a mail in the outgoing queue, or the sendmail
  599. Newsbase transport has queued a mail there.  You can kick it by choosing
  600. "Kick" on the icon bar menu (see "noiconbar" directive) or double-clicking on
  601. !SendSMTP (inside !FreeSMTP).
  602.  
  603. After being loaded, it will wait 30 seconds, then 1 minute, then 2, 4, 8,
  604. then 16 minutes, and thereafter every 30 minutes. This is in addition to the
  605. other times when it is kicked manually or by the server.
  606.  
  607.  
  608. Activity Log
  609. ------------
  610.  
  611. This software contains inbuilt activity logging which it will dump to
  612. the files clnt_log & mon_log inside the !FreeSMTP directory.
  613. The amount of debugging and which debugging is controlled by a file called
  614. area_log, also inside !FreeSMTP.  This contains one string per line
  615. containing a case-sensitive string to match against those used in the code. 
  616. (* is used as a wildcard which matches every string).  Examples of these are:
  617.  
  618.     domain_init
  619.     process_mail
  620.     verify_dest
  621.     
  622. Vital messages are always logged if possible.  The file is left open
  623. whilst the server is actively writing to it and closed after a short
  624. delay if nothing is written to it, for efficiency reasons.  The location
  625. of the log file can be altered by editing !Run and changing the settings
  626. of the three <SMTPServer$xxxxxLog> variables.
  627.  
  628. These will need to be cleared out every now & again.
  629.  
  630. If you place a line containing just a single * character in this file, then
  631. everything will be logged to this file, this will help provided more details
  632. if you are having problem.  If you send me this file when reporting faults,
  633. then it is more likely that I shall be able to help.  If you do this, then
  634. the log file will grow very quickly.  Only use it when attempting to capture
  635. debug trails for me.
  636.  
  637.  
  638. References
  639. ----------
  640.  
  641. RFC821 - Simple Mail Transfer Protocol
  642.  
  643. RFC1123 - Requirements for Internet Hosts
  644.  
  645. RFC1413 - Identification Protocol
  646.  
  647.  
  648. Bug Reporting
  649. -------------
  650.  
  651. There are bug reporting features built-in to the software.  If you edit
  652. the file !FreeSMTP.area_log and add a new line at the bottom containing
  653. just an asterix (*), then all debugging information will be sent to the
  654. files, and not just the really important ones.  These document some of
  655. the decisions made by the software and will contain justification for
  656. those decisions.
  657.  
  658. Please give as much detail as possible when reporting bugs.  Include the
  659. e-mail message that caused the problem if possible.  NOTE:  If you do not
  660. wish to disclose the identities of the sender/recipient, then please feel
  661. free to overwrite it with something else - use * characters for example -
  662. but please do NOT just remove it.  If you do choose to delete parts of it,
  663. then please only delete the bits before the @ in the address.  You may
  664. also like to remove most of the message body.
  665.  
  666. Bug reports to S.N.Brodie@ecs.soton.ac.uk please
  667.  
  668.  
  669. Technical Details
  670. -----------------
  671.  
  672. I have included this section for those who are interested.  It does not
  673. matter if you do not want to read any more of this document.
  674.  
  675. MX Records Explained
  676. ====================
  677.  
  678. Briefly.  You are probably familiar with the concept of hostnames (eg.
  679. customer.demon.co.uk, www.demon.co.uk, sunsite.doc.ic.ac.uk).  The mappings
  680. between these and the 4 byte numeric IP addresses (eg. 152.78.67.42) are
  681. registered in the Domain Name System's 'A' records (A for address).  Mail
  682. domains look very much like hostnames, and in some cases happen to be the
  683. same, but this is coincidence (but arranged like that because it's easier to
  684. remember :-)   Mail domains are also registered in the Domain Name System,
  685. but they do NOT map to IP addresses, but to 'Mail eXchangers'.  These mail
  686. exchangers are simply the hostnames of machines which handle mail for that
  687. mail domain.  For example, when software is using MX records to send me mail,
  688. it looks up the MX records for 'ecs.soton.ac.uk'.  The response it will get
  689. will be something similar to:
  690.  
  691. ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
  692. ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.
  693.  
  694. This indicates that bright.ecs.soton.ac.uk (which when looked up, is found to
  695. have the address 152.78.64.201) is a machine which handles mail for
  696. 'ecs.soton.ac.uk'.  landlord.ecs.soton.ac.uk is also reported as a mail
  697. exchanger (so when bright is down, we can still receive mail), but the lower
  698. number indicates that bright is the preferred exchanger, and landlord the
  699. backup.  If you perform a similar lookup on any Demon customer domain,
  700. usually you will find 4 or 5 records, with varying priorities.  Although it
  701. would appear that lots of DNS lookups are required in order to find the
  702. addresses of these mail exchangers, that is not the case typically, as the
  703. full response from the DNS for the question "ecs.soton.ac.uk IN MX" will be
  704. (if not querying one of our authoritative nameservers in Southampton):
  705.  
  706. Questions:
  707. ecs.soton.ac.uk. IN MX
  708.  
  709. Answers:
  710. ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
  711. ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.
  712.  
  713. Additional:
  714. bright.ecs.soton.ac.uk IN A 152.78.64.201
  715. landlord.ecs.soton.ac.uk IN A 152.78.114.230
  716.  
  717. Authority records:
  718. dns0.ecs.soton.ac.uk    inet address = 152.78.64.201
  719. dns1.ecs.soton.ac.uk    inet address = 152.78.114.230
  720. dns0.brad.ac.uk inet address = 143.53.240.2
  721. dns0.brad.ac.uk inet address = 143.53.2.5
  722. dns1.brad.ac.uk inet address = 143.53.238.5
  723.  
  724. ie. since it is assumed that you will probably want the IN A record for
  725. each mail exchanger, the DNS server includes those records in its answer
  726. which you may need.  Since you may not 'trust' the nameserver, it also tells
  727. you machines that are the authoritative DNS servers for the ecs.soton.ac.uk
  728. internet domain.  The auth records show the names of our primary and
  729. secondary DNS servers, plus our offsite authority nameserver (an Internet
  730. requirement) at Bradford.
  731.  
  732.  
  733. Remote host authentication
  734. ==========================
  735.  
  736. When a connection is accepted, the peer IP address is looked up in the DNS.
  737. Since this lookup is initiated immediately, then the lookup is often 
  738. complete before the HELO arrives (and the HELO parameter can thus be
  739. authenticated immediately).  The domain name specified as the parameter to
  740. HELO is used in the Received header which is added by the smtp server to
  741. the incoming message, together with either the IP address of the remote
  742. host, or the name as obtained from the DNS.
  743.  
  744. NOTE: Mail will NOT be rejected if the HELO domain fails to authenticate.
  745. This is RFC-compliant behaviour (it is not allowed to reject on the basis
  746. of the HELO domain).
  747.  
  748.  
  749. Remote user authentication
  750. ==========================
  751.  
  752. When a connection is accepted, then an ident request is sent to the origin
  753. machine requesting the user identity of the sender.  (This is not done if
  754. the configuration file contains a "noident" directive).  This is logged
  755. with area "ident" (so place "ident" in area_log to see it in smtp_log).
  756.  
  757. NOTE: You cannot rely on this, particularly on the user id returned. See
  758. RFC1413 for more details about the (lack of) confidence that you should
  759. have in the ident response.
  760.  
  761. NOTE 2: You might decide to disable this, but usually only because the
  762. overhead of establishing a TCP connection to the client wastes resources.
  763. The bandwidth used is negligible though (on average about 10 bytes out,
  764. and 25-50 bytes back).
  765.  
  766.  
  767. Attacks & Security Considerations
  768. =================================
  769.  
  770. Simple denial of service attacks are prevented (limits on number of
  771. recipients for message plus limits on number of concurrent connections)
  772. The recipient limit is set to 100 (minimum requirement in RFC821)
  773.  
  774. Idling attacks are repelled by implementing the timeout strategy given
  775. in RFC1123.
  776.  
  777. Well faked e-mail can never be detected successfully, but the addition
  778. of the Received header to incoming message bodies will assist in the
  779. tracing of injection points into the SMTP system.
  780.  
  781. Two log files are generated inside !FreeSMTP.  These are called
  782. clnt_log and mon_log, and are generated by the client and monitor+server
  783. respectively.
  784.  
  785. For the general mail security considerations see RFC821 and RFC1123.  In
  786. the RISC OS environment, a further consideration is that being a single-
  787. user operating system, there is no way to prevent the Newsbase being
  788. examined directly, or the outgoing queue to be examined, unless you have
  789. taken specific measures to make this so.
  790.  
  791. RFC1123 Considerations
  792. ======================
  793.  
  794. Incoming addresses in both MAIL FROM and RCPT TO fields are automatically
  795. rewritten as per RFC1123 to strip unnecessary source routeing from them.
  796. This happens before any other processing.  (This also has the effect of
  797. stopping hackers using source routeing as a way of using you as a mail
  798. gateway, since after the rewrite, the destination domain will no longer
  799. match a localdomain, and will be rejected unless you forward for that
  800. domain)
  801.  
  802. The %-hack is supported by the address rewriter too and explicitly
  803. removed, so hackers can't use that either.
  804.  
  805. Miscellaneous
  806. =============
  807.  
  808. When spooling files if the file cannot be opened in spool.mail.text.user then
  809. spool.fail.user is used instead (and the mail is bounced if that fails too). 
  810. Files in spool.fail.user are never touched again and need to be handled
  811. manually.
  812.  
  813. I am very interested in RFC compliancy issues. E-mail
  814. me any issues you find.
  815.  
  816.  
  817. ChangeLog
  818. =========
  819.  
  820. 1.20
  821. ----
  822.  
  823. Forwarding rules code clarified - shouldn't make as many mistakes.
  824.  
  825.  
  826. 1.19
  827. ----
  828.  
  829. Loopback interface is checked for presence and uppishness
  830.  
  831. Low memory situations are handled better.
  832.  
  833. Miscellaneous fixes.
  834.  
  835.  
  836. 1.16
  837. ----
  838.  
  839. The smtp_log left open problem is definitely gone now, because the file is
  840. gone too!  Everything is dumped in mon_log instead.
  841.  
  842. Aliases with capital letters in now work
  843.  
  844. The forwarder doesn't consider you a twat for not using MX records and
  845. constantly override that decision. :-)
  846.  
  847.  
  848. 1.14
  849. ----
  850.  
  851. Local spool directory changed to be spool.mail.text.*
  852.  
  853.  
  854. 1.13
  855. ----
  856.  
  857. Bug in sender fixed - it was treated the successfully connection being made
  858. to the server as an error :-/
  859.  
  860.  
  861. 1.12
  862. ----
  863.  
  864. Full release of the not grabbing all processing time version.  Also
  865. contains a bug fix that cures a misinteraction caused by two concurrent
  866. mail deliveries.  Log file closing finally sorted.  However, because of
  867. the fix, you can't view smtp_log whilst the server is running.
  868.  
  869.  
  870. 1.10
  871. ----
  872.  
  873. Should be better behaved and not grab as much processor time, which should
  874. help people using dialup links
  875.  
  876. 1.09
  877. ----
  878.  
  879. Log file should be closed successfully now
  880.  
  881.  
  882. 1.06
  883. ----
  884.  
  885. Mail can now be sent even without a terminating linefeed.  This would have
  886. caused mail to not be delivered.
  887.  
  888. 1.05
  889. ----
  890.  
  891. DNS Resolver bug fix
  892.  
  893. 1.04
  894. ----
  895.  
  896. RFC compliancy fix: doesn't try the A record if all the MX records fail.
  897. A records only used if no MX records were found.
  898.  
  899. Extra debug information put in to try to determine the cause of some
  900. apparent premature timing out.
  901.  
  902. Activity log notes in this document updated to cover bug reports.
  903.  
  904.  
  905. 1.03
  906. ----
  907.  
  908. VRFY fixed again!  It was rejecting non-local single recipient aliases
  909. because Newsbase was saying that the user was unknown.
  910.  
  911.  
  912. 1.02
  913. ----
  914.  
  915. Fixed domain name processing to not add surplus > characters
  916.  
  917. EXPN procession now works properly again
  918.  
  919.  
  920. 1.01
  921. ----
  922.  
  923. Fixed acceptfrom and rejectfrom handling - the bitfield masks were
  924. the wrong way around 
  925.  
  926.  
  927. 1.00
  928. ----
  929.  
  930. TRACE removed from the sendmail transport!!
  931.  
  932. maxhops added
  933.  
  934. Vital missing headers are added to incoming mail
  935.  
  936.  
  937. 0.11
  938. ----
  939.  
  940. You can disable the GUI by adding 'noiconbar' to the configuration file
  941.  
  942. Some of the log messages are clearer
  943.  
  944. Bug in sendmail transport file corrected
  945.  
  946.  
  947. 0.10
  948. ----
  949.  
  950. Very simple Wimp interface added
  951.  
  952. Some log messages have been changed to make them sound less fatal (some
  953. are purely informational but had alarming sounding overtones)
  954.  
  955. in_smtpd's sendmail reads the smtp-conf file to determine how to send
  956. mail to single recipients, instead of defaulting to MX records (when
  957. no gateway can be found, and none was given in Newsbase, multiple
  958. mails are generated to all of the recipients via MX records)
  959.  
  960.  
  961.  
  962. 0.09
  963. ----
  964.  
  965. Multi-line responses were confusing the SMTP sender because I'd got a
  966. condition test round the wrong way :-(
  967.  
  968. Lock files removed - the task list is scanned instead.
  969.  
  970. Long lines were confusing things all over the place.  Although illegal,
  971. some clients still generate this, so I allow them now too.
  972.  
  973. The socket sender had every chance of crashing if a line was to be
  974. transmitted which was longer than 256 characters!  This is now 
  975. upped to 1024 characters (something which calling routines already
  976. enforce)
  977.  
  978. SMTP Monitor uses an exponential backoff retry algorithm for sending mail
  979. when it is first started - it delays 30 seconds, then 1 minute, then 2,
  980. then 4, then 8, then 16, then every 30 minutes.  It can still be launched
  981. manually by running !SendSMTP and will be launched whenever you send mail
  982. locally.
  983.  
  984.  
  985.  
  986. Please e-mail me any problems: snb94r@ecs.soton.ac.uk
  987.  
  988.  
  989. --
  990. Stewart Brodie
  991. August 1997
  992.